Subject: AIW5 Capabilities Exchange Proposal

From: [email-masked]
Date: Tue, 2 Aug 94 12:21:17 EDT

Here are some comments to the 'AIW5 Capabilities Exchange Proposal' posted by
Frank Bordonaro.

>  Run-Time Capabilities Exchange
>  ------------------------------
>      Capabilities Exchange normally occurs at the
>      startup of the data link switch.  However,
>      Capabilities Exchange can also periodically occur
>      at run-time.  Run-time Capabilities Exchange can
>      only consist of the following control vectors:
>   1. Exclusivity CV,
>   2. MAC Address List CV,
>   3. NetBIOS Name List CV,

Please add the 'SAP List Support CV' to the above list. This was agreed upon at
AIW5 by both Peter Gayek and Wayne Clark.

>        +---------------------------------------------------------------+
>        |   SAP List Support (X'86') Control Vector                     |
>        |                                                               |
     .
     .
     .
     .
>           2       4                Supported SAP vector -  bitwise "OR" of
>                                    SAP masks for each supported SAP.
>                                    <mask>                <supp sap>
>                                    X'0001' - NULL SAP       X'00'
>                                    X'0002' - SNA  SAP       X'04'
>                                    X'0004' - SNA  Group SAP X'05'
>                                    X'0008' - SNA  SAP       X'08'
>                                    X'0010' - SNA  SAP       X'0C'
>                                    X'0020' - Span Tree SAP  X'42'
>                                    X'0040' - NetBios SAP    X'F0'
>                                    X'0080' - LNM SAP        X'F4'
>                                    X'0100' - LNM Group SAP  X'F5'
>                                    X'0200' - RPL SAP        X'F8'
>                                    X'0400' - Global SAP     X'FF'
>                                    X'0800' - X'8000' Reserved

I agree with Scott, DLSw should allow the setting of any SAP within this CV
Also, I was under the impression that a 16 byte bit vector was agreed upon
at AIW5 for the structure of this vector. I will include what I understand
that to look like.

        +---------------------------------------------------------------+
        |   SAP List Support (X'86') Control Vector                     |
        |                                                               |
        |       The SAP List Support control vector identifies support  |
        |       for SAPs by the sending Data Link Switch. Each bit in   |
        |       the SAP control vector data field represents a SAP as   |
        |       defined below. This vector is required.                 |
        |                                                               |
        +---------------------------------------------------------------+

        Offset  Length  Value       Contents
        ------  ------  -----       --------
           0       1    X'12'       Length of the SAP List Support structured
                                    subfield
           1       1    X'86'       key = X'86' that identifies this as the
                                    SAP List Support structured subfield
          2-17    16                the 16-byte bit vector describing all
                                    even numbered SAP's enabled.

                                    Each Bit within the 16 byte bit vector will
                                    indicate whether an even numbered SAP is
                                    enabled (b'1') or disabled (b'0').

                                    Each Byte within the 16 byte bit vector
                                    will be numbered from 0 - F. (In the
                                    following 1 byte example x would be
                                    equal to the appropriate byte number.)

                                    bbbb bbbb
                                    |||| ||||
                                    |||| |||SAP 'xE' enabled or not
                                    |||| |||
                                    |||| ||SAP 'xC' enabled or not
                                    |||| ||
                                    |||| |SAP 'xA' enabled or not
                                    |||| |
                                    |||| SAP 'x8' enabled or not
                                    ||||
                                    |||SAP 'x6' enabled or not
                                    |||
                                    ||SAP 'x4' enabled or not
                                    ||
                                    |SAP 'x2' enabled or not
                                    |
                                    SAP 'x0' enabled or not

>       +---------------------------------------------------------------+
>       |   NetBIOS Support (X'85') Control Vector                      |
>       |                                                               |
>       |       The NetBIOS Support control vector identifies support   |
>       |       for the NetBIOS protocol by the sending Data Link       |
>       |       Switch.  This control vector is optional.  If it is     |
>       |       omitted in a DLSw Capabilities Exchange, the sending    |
>       |       Data Link Switch may still support NetBios depending on |
>       |       the SAP List Support control vector. See below.         |
>       |                                                               |
>       +---------------------------------------------------------------+

After thinking this over for a bit, I'd like to propose that we drop the
NetBIOS Support Control Vector altogether. With the SAP Support List now
being declared required, the need for specific CAPex vectors for features
that are defined by a certain SAP is redundant. With Scott's question fresh
in our minds ("..... is DLSw going to support LNM?"), do we want to be
in a position where we have to add a new vector each time DLSw adds
additional support?

>        +---------------------------------------------------------------+
>        |   TCP Sessions (X'87') Control Vector                         |
>        |                                                               |
>        |       The TCP Sessions control vector indicates the support   |
>        |       of an alternate number of TCP sessions for the Data     |
>        |       Link Switching traffic.  The base implementation of     |
>        |       Data Link Switching supports two TCP sessions, one for  |
>        |       each direction of data traffic.                         |
>        |                                                               |
>        |       This control vector is optional.  If it is omitted in a |
>        |       DLSw Capabilities Exchange, then two TCP sessions are   |
>        |       assumed. It is further assumed that if a Data Link      |
>        |       Switch can support one TCP session, it can support two  |
>        |       TCP sessions.                                           |
>        |                                                               |
>        |       if TCP Sessions CV values agree, then                   |
>        |           use the number of sessions in CapEx                 |
>        |           if the number of sessions is one, then              |
>        |               if IP address of this DLSw > IP address of      |
>        |                  partner DLSw, then                           |
>        |                   drop the TCP session for port 2065          |
>        |               else                                            |
>        |                   do nothing: other DLSw will drop the extra  |
>        |                   TCP session                                 |
>        |               endif                                           |
>        |           else                                                |
>        |               do nothing: use 2 TCP sessions                  |
>        |           endif                                               |
>        |       else                                                    |
>        |           num TCP sessions disagree: use 2 TCP sessions       |
>        |       endif                                                   |
>        |                                                               |
>        +---------------------------------------------------------------+

I don't think it's appropriate to include the pseudo code here. Everything
described within it is already described in text. Please just add a text
description for the part about who drops a session when one is preferred.

Thanks,
 Steve Petriccione: [email-masked]
 Data Link Switch Development
 International Business Machines Corp.
 Research Triangle Park, NC

---

From: Frank Bordonaro <[email-masked]>
Date: Wed, 3 Aug 94 11:45:45 PDT

> AIW5 by both Peter Gayek and Wayne Clark.

Done.

> at AIW5 for the structure of this vector. I will include what I understand

Why did you only list the EVEN saps above? This does not facilitate the
setting of ANY sap by this CV, as Scott suggested. Your idea has the same 
problem as the original proposal if it doesn't include all saps.
If we go this route where DLSw can support any sap, then we need to make 
this a 32 byte vector. I originally wrote the proposal up this way, but 
thought sending a 32 byte vector for sap support was extreme. It now seems 
that if we don't allow for all cases, we'll likely run into trouble later. 

So, to set the base for continued discussion, the new proposal is
a 32 byte vector where the bits are numbered left to right (as above).
I think the RIG rules are that a proposal needs to be on the table for
3 weeks, before it can be resolved. Start the clock.

> in a position where we have to add a new vector each time DLSw adds

I second this proposal. However, since we have never worried about
redundancy in the SSP (the bigger the better :-), why take out a 
redundant CV. It just adds to the character of the protocol.
Forgive my sarcasm, I could not resist.

There should be minimal RFC 1434 backward compatibility issues with this 
proposed change, since 1434 does not address capabilities exchange, so maybe
we can get away with removing this. So let's start the clock on this
change and see what happens.
 
> description for the part about who drops a session when one is preferred.

Done.

>  Research Triangle Park, NC

Frank Bordonaro
cisco Systems, Inc.